User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

• Go to Help -> About
• The updater will run
• It will inform you that "firefox is up to date"
• Open a terminal (or a software center application like GNOME Software or KDE's Discover)
• Check for updates (flatpak update)
• Observe that there is an update available for org.mozilla.firefox

Expected results:

It should tell me that an update is available and offer to install it. I think this can be done with the Portal API (https://blogs.gnome.org/mclasen/2019/12/19/9100/) but would probably require code changes somewhere. I'm not sure which component this should be assigned to so am filing this in "Release Automation: Flatpak" for now. Feel free to assign this to a more appropriate component.

AFAIK, since flatpaks are sandboxed, we can't offer updates via our normal mechanism that we offer on vanilla Firefox installations. For that reason, there's a policy baked in the flatpak that disabls updates via the classic way and relies instead on the Flathub mechanism. So this is expected behavior.

That's why I flagged this as an enhancement rather than a bug.

The current behaviour is counter-productive. It pretends to check for updates even though it's actually not doing anything.

This bug is a proposal to wire up the updater code to the portal API so that firefox can recognise when updates have been pushed to flathub.

Linux Distros build Firefox with:

ac_add_options --disable-updater

which disables the check. We may need to add it to Mozilla flatpak too.

Going forward, Flatpak-related bugs will no longer be filed under RelEng, but instead in Core/Widget:GTK where folks have much more in-depth knowledge on this. If the issues are RelEng related, they can be filed against Release Engineering :: Release Automation: Other and we'll take care of that.

Mihai, can we add the

ac_add_options --disable-updater

build option to flatpak builds?
Thanks.

Hm, not sure this is traightforward to do since flatpak is merely a repack of the Linux64 tarball. In the release automation, we're manipulating that to bake the l10n and other necessities for the flatpak to be built, but we're not touching its build at all so not sure how to inject that param other than at build time.

We already disable the updates in a couple of places like this and this but I presume that some of the updater logic is still trying to do that as comment 2 mentions.